CI: Update Release workflow for LocalStack Python SDK #20
CI: Update Release workflow for LocalStack Python SDK #20
Conversation
giograno
left a comment
giograno
left a comment
There was a problem hiding this comment.
Thanks for tackling this!
I have only a minor question about the uv.lock file. Maybe @alexrashed has some suggestions.
| git config user.email ${{ env.git_user_email }} | ||
|
|
||
| - name: "Commit changed code" | ||
| - name: "Commit Changed Code" |
There was a problem hiding this comment.
I am wondering if we should try to commit the uv.lock file here as well. It's true that we won't get the same issue anymore downstream, but maybe it's good to keep it updated.
There was a problem hiding this comment.
Not sure I understand / have the full context here.
Does the pyproject.toml change here? If so, then the uv.lock file definitely needs to be updated (without upgrading the dependencies in there) and commited.
Everything else (like upgrading the versions in the uv.lock) should in my opinion not be part of the release workflow (way too fragile!), but should rather be handled with weekly updates proposed by dependabot (or any other kind of automation).
There was a problem hiding this comment.
But I am still not sure if I understood this correctly, also happy to jump on a huddle to discuss this directly / look at this together.
There was a problem hiding this comment.
No pyproject.toml wouldn't change here. In the previous releases, we first tagged the release commit and then ran make install publish. uv.lock was unstaged, and this resulted in a dev version being pushed to PyPi. This should not happen anymore, but I was wondering when is a good time to commit an update to uv.lock. As you suggested, some sort of automation would be the best.
3 participants
Changes + Motivation
make installaltering theuv.lockfile and hence inferring the published version incorrectly.v2026.4.0, the version inferred bysetuptools_scmshould be2026.4.0but since there were changes made to theuv.lockfile it was instead inferred asv2026.4.1.dev0which is not the version we want published.make publishinstead ofmake install publishas @giograno identified it was a result of runningmake install.